refactor(distribution): automate release procedure#1069
refactor(distribution): automate release procedure#1069christianlangevin merged 1 commit intoMODFLOW-ORG:developfrom
Conversation
fc418ad to
0283171
Compare
0283171 to
a591a0e
Compare
aaa7a58 to
de0432f
Compare
83aac30 to
9abeee4
Compare
9abeee4 to
abd68ab
Compare
christianlangevin
left a comment
There was a problem hiding this comment.
Few minor things that might need to be adjusted, based on recent changes to develop.
| @@ -16,8 +16,8 @@ module VersionModule | |||
| ! -- modflow 6 version | |||
| integer(I4B), parameter :: IDEVELOPMODE = 1 | |||
| character(len=*), parameter :: VERSIONNUMBER = '6.4.0' | |||
There was a problem hiding this comment.
This was updated to 6.4.1 on develop. I think we also need to do that here.
There was a problem hiding this comment.
Tentative solution discussed via DM and reproduced below for posterity:
The release workflow automatically sets version files to the version specified in the name of the branch triggering the workflow. IDEVELOPMODE is also set to 0. These changes are included in the PR opened against master from the release branch. After the release is approved and changes are merged to master, another PR is opened against develop to update from master, reset IDEVELOPMODE to 1, and increment the minor version number in preparation for the next minor version release.
Patch releases are generally expected to branch from master, since develop may contain broader-scoped changes. Minor version releases are generally expected to branch from develop.
0ea2603 to
9ade80b
Compare
* use pathlib in distribution scripts * construct relative paths from script locn, not cwd * synchronize version file updates with file lock * rename mkdist.py -> build_dist.py * rename evaluate_run_times.py -> benchmark.py * rename make_release.py -> update_version.py * introduce build_docs.py * add argparse CLI for each script * add tests/test configuration for scripts * add post-build checks for distribution * move .fprettify from distribution/ to proj root * add release.yml to automate release procedure * add release documentation to distribution/README.md * add path argument too mk_runtimecomp.py * deduplicate mf6 -v version string output * add bin/sh header to Unix example scripts * update version string substituted into docs (<version>---Release Candidate -> <version>rc) * test distribution scripts in CI test job * cache example models in CI test job * ignore ci.yml on md/docs changes
9ade80b to
b0208d9
Compare
This PR refactors
distribution/scripts, documents release-related procedures indistribution/README.md, and automates the release process.Distribution scripts
Scripts are updated to use
pathlib. Each is given anargparseCLI. Shared utilities are moved todistribution/utils.py. Tests for the scripts are updated to usepytesttempdir fixtures. More test cases are added. Some tests modify files in the repo and clean up after withgit restore, so the tests indistribution/shouldn't be run in parallel. Care should also be taken before running the tests locally, as they will restore files indoc/,make/, andutils/. Other changes include:__file__) instead of current working directorydistribution/)meson_build()frommodflow-devtoolsevaluate_run_times.py->benchmark.pymake_release.py->update_version.pymkdist.py->build_dist.pybuild_docs.pyautotest/build_mfio_tex.pybuild_nightly.pybuild_dist.py --developmentThis changeset allows the
MODFLOW-USGS/modflow6-nightly-buildrepo to usedistribution/build_dist.py, making it unnecessary to have a separatemake_distribution.pyscript andrequirements.txtin that repoRelease automation
A new CI workflow
release.ymlis added to automate the release procedure. The workflow is triggered when a release candidate branch is pushed to theMODFLOW-USGS/modflow6repository. The branch name must follow semantic versioning conventions, with or without anrcsuffix to indicate whether the branch is approved for release (for instance,v6.4.0rc). The workflow first builds modflow6 binaries, then downloads examples, benchmarks and documentation via the GitHub API (only building them if needed), then finally zipping everything up for distribution. It is largely identical to the procedure previously outlined at the top ofmkdist.py, except thatmodflow6-examplesrepository if availabledocs.yml) if availableMore extensive docs for the procedure are added to
distribution/README.md.Triggering a release
Under this scheme, a new release candidate build can be triggered by creating a branch named
v<semver>rcfrom the top ofdevelopand pushing it to this repository.If the branch name ends with
rc, it is considered a release candidate and the workflow is a dry run, building, testing and creating artifacts with development mode binaries then stopping short of a release. If the candidate build passes, it can be promoted by removingrcfrom the branch name and pushing the new branch — this will trigger the release workflow in production mode, rebuilding with develop mode off. If/when the build succeeds, a draft PR is autocreated against themasterbranch. The release can be approved by merging PR intomaster, which triggers a final job to create a tagged draft release, upload distributions and release notes to it as assets, and autocreate another PR to reinitializedevelopby updating frommaster, reset version files, and setIDEVELOPMODEback to 1. The release can be finalized by reviewing the draft release post, substituting in citations and any other additional content, and publishing.Miscellaneous
docs.ymlCI jobs toubuntu-22.04for compatibility with GCC 12.fprettify.yamlto project root (not solely distribution-related)src/Utilities/comarg.f90to de-duplicate version string output frommf6 -v(and add test)pathCLI arg todoc/ReleaseNotes/mk_runtimecomp.pyto specify dist locnpytest-casesandpytest-dotenvtoenvironment.ymlci.ymlon changes to markdown files or docs